Session Initiation Protocol (SIP) is an application-layer control (i.e., signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions may include Internet-based telephone calls, multimedia distribution, multimedia conferences, instant messaging conferences, interactive voice response (IVR), automated and manual operator services, automatic call distribution, call routing, etc. SIP invitations or SIP INVITE requests may be used to create sessions and may carry session descriptions that allow participants to agree on a set of compatible media types. SIP may use proxy servers to help route requests to a user's current location, authenticate and authorize users for services, implement provider call-routing policies, and/or provide other features to users. SIP may also provide a registration function that allows users to upload their current locations for use by proxy servers.
Typically, SIP uses SRV DNS (Domain Name System) record resolution, per Internet Engineering Task Force (IETF) documents RFC 3263 and RFC 2782, for the purpose of load balancing between multiple SIP servers. The load balancing algorithm described in RFC 2782 may be ideally suited for load balancing of SIP servers, but a TTL (Time To Live) parameter provided in the DNS record resolution is usually set to a duration on the order of a few hours. As a result, capacity changes or outages in SIP servers cannot be communicated effectively using such a DNS mechanism because it is too slow.
For example, a SIP server may have a finite set of resources with which to service calls (e.g., digital signal processing (DSP) resources on an IVR server may be limited to three-hundred simultaneous calls). DNS-based load balancing per RFC 3263 and RFC 2782 would attempt to balance new SIP dialogs between multiple SIP servers without any consideration for the number of calls already in progress. The DNS TTL parameter makes it impossible for the SIP server to timely revise its traffic allocation to account for current resource availability because any change to traffic allocation would not occur for hours. By the time the revised traffic allocation is implemented, the allocation value has been superseded numerous times, and any call blockages intended to be avoided by load balancing have long since occurred.